This invention relates generally to identifying files in computer operating systems and specifically to reconstructing a pathname from a file handle maintained by an operating system.
Traditional computer operating systems use various ways to organize and manage files stored within a computer. One popular way to organize files is with a directory structure that allows files or directories to reside within other directories. When a directory resides within another directory, the residing directory is referred to as a "sub-directory." A file ultimately resides in a "parent" directory. The file's parent directory may, in turn, have a parent directory, and so on, thus creating a hierarchy of directories. This hierarchy of directories, each of which may contain files and additional directories, results in a directory tree structure such as the one shown in FIG. 1A. In order to access a particular file, each of the parent directories in a chain from a starting, or "root," directory are named in a string, along with the file's name. The resulting string is called a "pathname."
FIG. 1A shows a prior art directory structure including root directory, "directory1," which contains files such as "file1," "file2," "file3" and "file4." Directory1 also includes directories directory2 and directory3. Directory2, in turn, contains files file5 and file6. Directory3 contains files file7 and file8 and also contains directories directory4 and directory5. Directory4 contains files file9 and file10. In practice a directory can contain any number of files or directories.
The operating system allows a user of the computer system to create, access and manipulate files and directories within a directory structure such as the directory structure shown in FIG. 1A. For example, a user can create a file and specify that the file be placed in a particular directory. The user can also delete or move files. Similarly, for directories, the user can specify that a directory be created or deleted. Some operating systems, such as operating systems based on the UNIX.RTM. operating system (i.e., UNIX.RTM.-like operating systems), allow a user to create "links" between files so that a file can be accessed by more than one name.
In FIG. 1A, file7 is referenced by the text string "/directory1/directory3/file7". The directory, directory1, is referred to as the "root" directory and is always given as the starting directory in a pathname where the pathname specifies an absolute path to a file. An absolute pathname uniquely identifies any file within a given file system without requiring further information. Another form of pathname is a relative pathname, which identifies a file by using the relative path and a reference point such as a "current" directory or starting point.
For example, in a relative path, assuming the current directory is directory3, file7 may be referenced merely by giving the name of the file as "file7". Another example of a relative path, assuming the current directory is directory1, is to use the path "directory3/file7" to access file7. For ease of discussion, this application describes the invention in terms of absolute pathnames. It will be apparent that the concepts presented herein are equally applicable to relative pathnames. For general information on the UNIX.RTM. directory structure and pathnames consult, e.g., ISO/IEC 9945-1, IEEE 1003.1-1990.
While pathnames are convenient ways for human users to specify directories and files, the operating system uses a more computationally convenient internal representation of a pathname called a "file handle". Typically, a file handle is a unique number or group of numbers and may also include other information that uniquely identifies an item such as a directory or file residing within the computer system.
In UNIX.RTM.-like operating systems file handles include numbers called "inode" numbers. A unique inode number is assigned to each file and directory within a directory structure or "file system". The file or directory may be equivalently referenced by its name or file handle. For purposes of discussing the present invention, the inode number is considered to be equivalent to the file handle for a given file in a file system in a UNIX.RTM. operating system.
FIG. 1B is an example of a directory tree structure in a UNIX.RTM.-like operating system. Rather than use the descriptive names of, e.g., "directory1," "file1," etc., more typical names are used such as would be encountered in a UNIX.RTM.-like system. For example, the root directory is given the label "/" while the two directories shown in FIG. 1B are labelled "usr" and "usr1". Note also, in FIG. 1B, that the names for directories and files (e.g., files "x," "y," and "z") are placed adjacent to the edges of the graph of the directory structure. Instead of file and directory names at the nodes of the directory graph as in FIG. 1A, the inode numbers shown in FIG. 1B are placed at the nodes. This illustrates the operating system's point of view that files and directories are represented by file handles (i.e., inode numbers). The inode numbers are shown as numeric values in parentheses. The inode numbers are associated with data structures that hold "meta data" for each file or directory. The meta-data includes information about the associated file or directory such as size, creation date, access rights, etc.
In order to translate, or "resolve" a pathname to an inode number (i.e., a file-handle) the names adjacent to edges in the graph are combined proceeding from the root directory to the file desired. For example, file "y" is shown with an inode number of 6 (or simply, "inode 6"). The pathname for inode 6 is "/usr1/y". In FIG. 1B, the root directory has inode number 2, directory usr has inode number 3, etc. Note that, within pathnames, the individual file and directory names are separated using the slash ("/") character. For example, the pathname to inode number 7 is "/usr1/z".
Each file resides on a file system where a file system represents one or more disk drives. The file system containing the root directory is called the root file system. Each file system has its own file hierarchy headed by a root directory. The inode number for a root directory is always, by convention, the number 2. Inode numbers are unique within a file system. File systems are grafted onto the root file system by a process called mounting. For example, if file 5 ("/usr/x") is a directory then a second file system could be mounted on that directory as shown in FIG. 1C.
In FIG. 1C, File System 2 has been mounted on File System 1 at the directory with inode number 5 ("directory5") of FIG. 1A. Note that, after the mount, the root directory of File System2 has effectively replaced File System 1's directory5 in the file hierarchy. Directory5 will not be visible until File System 2 is unmounted. Once the mount has taken place, access to files in File System 2 is made with pathnames beginning with "/usr/x". For example, to access file 6 in File System 2, the pathname "/usr/x/q/s" would be used.
The process of locating a file using a pathname is called pathname resolution. The product of pathname resolution is a file handle. A file handle is used by the operating system internally to refer to a file without having to resolve the file's name again. The file handle returned is typically a combination of the file system number (usually called a device number) and the inode number. Herein, file handles, are represented using a pair of integers enclosed by parentheses (e.g., (2,6)).
Renaming files across file systems is not allowed (for example, in FIG. 1D it would be illegal to rename "/usr1/y" to "/usr/x/p/f").
A useful feature of UNIX.RTM. systems is that files can have more than one name, although most implementations allow directories to have only a single name. The link() system call is used to add a new name for an existing file. For example, if the call link("/usr/x/q/r", "/usr/x/p/f") were made in an operating system including the directory structure of FIG. 1C, the result would be as in FIG. 1D. Now either of the pathnames "/usr/x/q/r" or "/usr/x/p/f" can be used to access file (2,5). Note that this is not a situation where one name is the primary name and the other is an alias--both names can be used equally and the original name can be removed without affecting the new name.
As is the case with rename, the link() system call generally does not allow links between file systems.
A problem exists with the file organization in that, given a file handle, there may be more than one pathname that resolves to the file represented by the file handle. This makes it difficult to regenerate a pathname based on a file handle. For example, given file (2,5), because of the link call discussed above, there would be two possible pathnames to the file. With only the limited information provided by the inode number, it is impossible to tell which pathname was originally used to create the file handle, i.e., the inode number.
Therefore, it is desirable to have a system where a file handle that is one of multiple file handles for the same file can be used to regenerate the pathname that was originally resolved to create the file handle. Such a system would be useful, for example, to generate a pathname that was used to open a file in the case where the file has several file handles and pathnames.